@fabpot is there anything else left to be done for this PR in order to get it merged?

Is there a reason why you don't use the Yaml component to parse / dump the routing_dev.yml file?

@bamarni good point... I think it's because I'm just a noob and I've totally forgot about it :)

I'll fix that when I'll get home tonight. Thanks for pointing it out to me :)

@bamarni @dlsniper Parsing/dumping the yaml file would drop any comment in it, so it is a bad idea IMO.

@stof: I think it's the safest solution, as a user running this command, I'd understand if there is some changes on the file presentation, because a tool processed this file, all I would care about is that it remains a valid YAML file and it doesn't remove any of my other routes.

I think I've covered most of the use cases but imho users should do changes to the acme demo route to the dedicated file not to the routing_dev file.

If no one else has something to add to this then is this ok to be merged? cc @fabpot

Thanks!

I've added the change for using the Filesystem component to remove the directory. Is this mergeable now?

DId you see #434? There is also some config for the demo in security.yml.

Btw I'm thinking about an alternative solution, maybe instead of adding a self remove command in AcmeDemoBundle, it would make more sense to have one in SensioGeneratorBundle for example?

And its goal would be to replace the current app by a skeleton app, no matter what exists, it would be overwritten. Its name could be app:reset, app:clear or something like that.

@bamarni Thanks for pointing that issue out, I didn't knew it.

Also, I've thought about adding it there in the first place but I also wanted for it to be more of a sample on how to create console commands in Symfony as that part was missing and for people who just want to download the demo and snoop around the code it's nice to have it exposed there.

Also I'm not too keen on making some sort of command like that available as some might just run it into production, don't under estimate the power of users ;) and also if such a command is available it would be much harder to implement as detecting all the user bundles and so on just looks too much for my time right now.

If such a command would appear it would be nice indeed but, again, it's not the scope of this PR :)

@dlsniper : I get what you mean. I've submitted a PR for the security : symfony/symfony#5908

Btw I've tried the command, but it didn't removed the bundle from my AppKernel, and imo it should delete the src/Acme folder instead of src.

@bamarni Thanks. I'll have a look on it tonight and make it work.

@bamarni once your patches get merged I'll add support for them in here. Thank you for helping out!

if symfony/symfony#5908 and schmittjoh/JMSSecurityExtraBundle#85 get merged, this config would disable security :

jms_security_extra:
    enabled: false

security:
    enabled: false

@bamarni Removing the AcmeDemoBundle part of the security config is not equivalent to disaling the whole SecurityBundle: it would not remove the AcmeDemoBundle part (meaning you still have to remove it when you enable security again) and it would break your project if you already added your own security stuff and rely on it.

@stof: well removing the demo bundle should mean disabling security, as there wouldn't be anything to secure then.
But yes it looks like a too rude way, then what would a default config looks like? Imo the only part really tied to the demo is the firewalls, the rest could be considered as a default (even the in-memory provider), for example this one would work without patching anything on securitybundle :

jms_security_extra:
    secure_all_services: false
    expressions: true

security:
    encoders:
        Symfony\Component\Security\Core\User\User: plaintext

    role_hierarchy:
        ROLE_ADMIN:       ROLE_USER
        ROLE_SUPER_ADMIN: [ROLE_USER, ROLE_ADMIN, ROLE_ALLOWED_TO_SWITCH]

    providers:
        in_memory:
            memory:
                users:
                    user:  { password: userpass, roles: [ 'ROLE_USER' ] }
                    admin: { password: adminpass, roles: [ 'ROLE_ADMIN' ] }

    firewalls:
        dev:
            pattern:  ^/(_(profiler|wdt)|css|images|js)/
            security: false

        main:
            pattern:  ^/$
            anonymous: ~

    access_control:
        #- { path: ^/login, roles: IS_AUTHENTICATED_ANONYMOUSLY, requires_channel: https }
        #- { path: ^/_internal/secure, roles: IS_AUTHENTICATED_ANONYMOUSLY, ip: 127.0.0.1 }

@bamarni I saw many people starting to work on their own stuff before removing the demo. So assuming there is nothing to secure is wrong.

@stof : I don't think those people are concerned by this command. Removing demo related stuff is an installation step (https://github.com/symfony/symfony-standard#4-getting-started-with-symfony), as such it should be done before starting to code.

As soon as you start to develop, this is not a demo anymore and it becomes your project, and there is no reliable way we can get this command working for every single use case once the development is started.

That's why imo this command should just overwrite security.yml.

@stof so what should we do about the security.yml file then? Add an option to this command to clean it up or not maybe?

👍 to @bamarni post above.

I agree with @stof. Many people start their project before trying to remove the Demo. They probably want to have it in place so they can compare their stuff to the Demos. So the command should try its best to remove the Demo without touching user stuff. And if that can not safely done, it should still remove as much as possible and warn that it could potentially interfere with custom stuff (maybe print what has been removed).

ping @fabpot @schmittjoh, we're not sure on how it should behave for security.yml, what is your opinion on this?

I think that we need clear instructions on how to remove the Acme demo code by hand. I'm -1 on added a CLI command to do that automatically.

@fabpot : ok, is it because you want this step to be an opportunity for beginners to see how a bundle is defined, routing is registered, ... ?

Then an alternative could also be not to promote this as the "official" way in the README, this is still really useful if it's not your first project and you just want to quickly install a ready-to-use app.

@fabpot a clear list of what needs to be done to remove the demo part would be a good idea indeed.
But I've often found myself wanting to remove all the Acme 'bloat' and just start with something fresh.
Also, like mentioned, there's no demo for a command in the bundle currently and it also presents some useful to learn things like using the Finder component. I know all of this info is in the manual but this adds some value on user interaction with the full stack framework imho.

I agree that removing the AcmeDemoBundle example is the very first step, when you start a new project. But the concept to add a CLI command to do it is ridiculous. When you start a new project you will need not only to remove ACME but also to include FixturesBundle, FOSUserBundle, to name a few. Will you create another CLI commands to extend your distribution? Surely, not.

In my opinion the best method to tailor satisfactory Symfony 2 distribution is to create a dedicated git branch, that contains all the customization:

https://github.com/gajdaw/symfony-standard/tree/2.1-startup

Whenever Symfony 2.1 branch receives a new tag, I merge it and get my distribution updated.

This is so far the best solution I've tried.

Anyway, I'm -1 on using CLI for this customization.

This is about simplifying a mandatory installation step, not "customisations" or personal preferences.

What does it mean installation? AFAIK there is not central Symfony 2 installation in the system. You take the distribution and start working on your project. This means, that each new project will require similar steps. You can call them installation, if you insist. But the fact is that you need to repeat the same changes everytime you start afresh. As I said before, I think that the best method to do these preliminary steps is to use dedicated git branch.

By installation I mean the instructions you find on the official documentation. What your talking about is indeed interesting but targeted to advanced users.

@gajdaw just because you use Fixtures or FOSUser as bundles it doesn't mean all people are using them. On my last 3 applications I've just skipped them and most likely I'll skip them as well in the future if they won't be needed in the applications I develop. On the other hand, Acme is always there, you always need to remove it. So why is that called ridiculous instead of automation?

Also, I don't use that system, with git branching so just because you use it it doesn't mean that others must do it as well.. That's actually a ridiculous thing to think :) Or if you want another ridiculous thing, let's have a manual entry to point for the link you've mentioned ;)

And like I've already said, this is about having a feature for new people trying the framework, not for those who used it already. It's called an enhancement for usability and a user friendly approach to solve a rather long/boring process which, if not done correctly, could give you some errors. It also provide a bit more insight into awesome features that aren't currently covered in the demo.

I don't see why a framework wouldn't want to be as user friendly as possible. @gajdaw, do you?

I prefer calling these installation steps (those in https://github.com/symfony/symfony-standard#symfony-standard-edition) than customizations.

Removing the demo bundle is one of the first steps of creating your new project, and you should take as it is just that. A demo bundle that shows you your application works after the other installation steps and provides a code example and how easy it is to create a working application.

All applications need a demo bundle removing, not all need a user bundle or fixture/migrations (some sites don't need a DB/User system).

@fabpot Do you think it's worthwhile to investigate this further for adding it to 2.2, both as functional demo for the mentioned components as a utility helper, or this should be closed?

Guys, you should read the previous comments in the discussion. the answer is already there: #412 (comment)

May be you should close this PR.

@dlsniper Maybe I used to strong word: ridiculous. Sorry. The command to remove a bundle surely is not ridiculous. But it should keep config files untouched (you can not process them, remove comments etc.).

The point is that removing ACME is in fact trivial. (Really, have you ever got any errors or problems with removing it? I doubt it :-)) I think the discussion is started because it is done again and again, in every new project. You can solve it preparing your own zipped distribution without ACME. This solution doesn't require git or other tools. It's pretty simple and works fine.

At some point you will find this procedure insufficient. For me that was the moment to use git branches.
Maybe this solution is not ideal - but so far I see no drawbacks. I do not force you to use it - I just share my solution of this problem :-)

@unknownbliss You say "Removing the demo bundle is one of the first steps of creating your new project". What other steps (apart from removing Acme) do you have in mind? I gave two trivial examples (FOSUserBundle, Fixtures) and there were voices against it. If there is nothing we can define as common, the installation will become removing Acme.

Do you really want to call the procedure of removing Acme "Installation of the framework"?

I'll close this for now :)

I know this issue is closed, but maybe a good idea is just add an option on Installation module that enables you to install AcmeBundle, if wanted.